Computer networks provide an efficient way to exchange information between two or more computers. Various types of computer networks are utilized including private networks, e.g. a local area networks (LANs), and public networks, e.g. the Internet. Often, the information exchanged between computers is of a sensitive or confidential nature. For example, to purchase goods or services via the network, a user is required to enter payment information such as a credit card number. Similarly, users routinely transmit sensitive and confidential business information over networks.
Information is exchanged over networks according to a protocol, such as the Internet Protocol (IP). IP was designed to allow for an open exchange of information; however, standard IP was not designed to protect information from unauthorized access. Accordingly, standard IP does not prevent an unauthorized user from receiving, viewing, and even modifying information transmitted over a network. Standard IP lacks other features such as authentication of users and network devices.
To address the lack of security provided by standard IP, the Internet Engineering Task Force (IETF) has developed a set of protocols, referred to as the Internet Protocol Security (IPSec) suite. IPSec provides protocols that conform to standard IP, but that include security features lacking in standard IP. Specific examples of IPSec protocols include an authentication header (AH) protocol and encapsulating security protocol (ESP). The ESP protocol, documented mainly in IETF Request for Comments (RFC) 2406, is an authenticating and encrypting protocol that uses cryptographic mechanisms to provide integrity, source authentication, and confidentiality of data. The AH protocol, documented mainly in IETF RFC 2402, is an authentication protocol that uses a hash signature in the packet header to validate the integrity of the packet data and authenticity of the sender.
Prior to using the ESP, AH or similar protocols, a first computer and a second computer in communication over the network must negotiate a set security parameters. The first computer begins the negotiation and is usually referred to as an initiator. The second computer is referred to as a responder because it is responding to a request from the initiator. The negotiated security parameters are stored in the initiator and the responder as one or more data structures referred to as a security association (SA). Parameters stored in the SA identify a security protocol (e.g. ESP or AH), a cryptographic algorithm used to secure communication (e.g. DES, 3DES), keys used with the cryptographic algorithm, a life time during which the keys are valid and the like.
One method of negotiating security parameters is by using a separate negotiation protocol. An example of a negotiation protocol is the internet key management and exchange protocol (IKE), also provided as part of IPSec and documented in IETF RFC 2409. The IKE protocol includes two phases. In a first phase, known as “main mode,” the initiator and the responder establish an IKE SA thereby creating a secure channel for conducting IKE negotiations. In a second phase, known as “quick mode,” the initiator and the responder use the IKE SA to negotiate general purpose SAs over the secure channel established in the first phase.
An IKE negotiation can fail for various reasons. As one example, the initiator and the responder can fail to agree on an acceptable set of security parameters. The initiator can attempt a new IKE negotiation by proposing different security parameters. However, IKE does not provide a mechanism for the initiator to predict whether the responder will accept the different set of proposed parameters. Accordingly, the new IKE negotiation may likewise fail.
Moreover, IKE provides for machine authentication, but not user authentication. Thus, while it is possible to verify the identity of a particular machine, it is not possible to verify the identity of a particular user. Some methods have been developed to incorporate user authentication into IKE using other known protocols such as Kerberos. However, these methods require that a new IKE main mode be conduced in conjunction with each user authentication.
Compatibility issues also exist when some protocols are combined with IKE. For example, when the initiator sends a request to the responder in clear text, meaning not according to a security protocol, and the responder requires secure communication, the responder initiates an IKE negotiation. When this occurs, the responder effectively becomes the initiator and the initiator effectively becomes the responder thereby subverting the roles of the initiator and the responder. Protocols, such as Kerberos, are sensitive to the direction of the negotiation and can fail when the roles of initiator and responder are subverted.